Many companies use a hosted telephone platform as a call management system in order to manage incoming and outgoing telephone calls to and from their internal telephones. In conventional systems, this involves implementing a phone system which is controlled by a common management application which acts as the hosted telephone platform, to which all telephones which belong to a company (or “subscriber”) are connected. Each telephone in the system is assigned an extension code, typically of three or four digits in length. Additionally, each telephone may be assigned a direct-dial-in (DDI) number, which enables a phone which is external to the system to call a phone within the system. Any calls placed by a phone within the system are handled by the management application prior to being forwarded to an external telephone network. Correspondingly, the management application handles all incoming calls from external telephone networks, and forwards the calls to the appropriate telephone within the system.
One of the most commonly used management applications that provides the functionality of a hosted telephone platform is provided by CISCO, and is known as CISCO Unified Communications Manager (CUCM or CallManager). CUCM is installed on a server, and is configured to manage a particular subscriber's phone system. Installing and configuring an instance of CUCM is very costly, in part due to the high cost of the software licence, and also because the software is extremely complex and difficult to configure. The software is not designed to be user-friendly, and therefore only people with significant levels of training are able to configure the software for each subscriber.
Previously, each subscriber would have required a server with CUCM installed on it in order to manage their telephone system. However, in line with recent moves towards virtualisation and cloud computing, it is now more common for several subscribers to share a single server, with the server divided such that several instances of CUCM are installed on it, with an instance of CUCM for each subscriber. This deployment configuration is referred to as a Hosted Communications Solution (HCS), and is available to service providers from CISCO.
The physical specifications of the server, i.e. the memory and processing power available, place an upper limit on the number of instances of CUCM which may be installed on HCS. This therefore restricts the number of subscribers that can share that physical server. Also, in such systems there may be a restriction placed on the minimum number of users attached to each instance on CUCM. This therefore restricts the type of subscriber that can use such systems to those with a minimum number of associated users. Clearly, subscribers with a low number of associated users are unlikely to use such systems in any case, due to the high costs outlined above.
A single clustered instance of CUCM can accommodate up to 75,000 individual users. This is very useful for larger organisations, for which CUCM offers the benefit of being able to handle the entire organisation with a single cluster. However, for smaller organisations having a fraction of the number of users, much of this capacity is unused. This is wasteful in terms of hardware utilisation, and also raises the relative cost for the organisation, as the hardware cost and main licensing costs for the CUCM software are not substantially different to those for a much larger organisation. In fact, CISCO places a lower limit on the number of users that subscribers to such systems must have, typically 50.
A known alternative approach for implementing a CUCM based hosted telephone platform to those outlined previously is illustrated in FIG. 1. This implementation enables multiple subscribers to use a single instance of CUCM.
As shown in FIG. 1, in the known system a middleware application in the form of an interface module 10 is implemented to interface between the subscribers 12 and CUCM 14. The interface module 10 acts to effectively combine multiple subscribers 12 into a single subscriber 12, such that multiple subscribers 12 may be handled by a single instance of CUCM 14 in a multi-tenancy arrangement.
Clearly, there are several benefits to such a system. Firstly, the cost to each subscriber 12 is reduced, as they need only pay for a portion of the CUCM instance. Secondly, this arrangement raises the number of subscribers 12 that can share a single server, thereby reducing hardware requirements. This reduces the power requirements of the system, and also the cost. Furthermore, by allowing multiple subscribers 12 to share a single instance of CUCM 14, the system is able to reduce the number of users that each subscriber 12 must have. This is because the cost of implementing the instance of CUCM 14 is split between multiple subscribers 12, so it becomes more cost effective for subscribers 12 with lower numbers of users. Also, because the subscribers 12 are pooled together, the lower limit of typically 50 users applies to the pool of subscribers 12, rather than to each individual subscriber 12. Therefore, this approach opens up usage of CUCM 14 to subscribers 12 having less than the lower limit of the number of users, and indeed individual users can join the system as subscribers 12.
As shown in FIG. 1, two subscribers 12 (Company A and Company B) connect to a common interface module 10, which in turn connects to an instance of CUCM 14 which is installed on a server. CUCM 14 in turn connects to an external telephone network 16. Clearly, it is important that the system separates Company A from Company B, so that each subscriber 12 effectively has their own contained system. If subscribers 12 are not separated, each subscriber 12 is able to see the other subscribers 12 on the system. Therefore, for example, Company A would be able to see users associated with Company B, and furthermore users from Company A would be able to dial users belonging to Company B using internal extension codes. Such a situation is clearly undesirable.
Therefore, the interface module 10 ring-fences each subscriber 12 from all other subscribers 12, as indicated by the dashed line in FIG. 1. As the subscribers 12 do not interface directly with CUCM 14, they are not able to see one another. However, as there is only a single instance of CUCM 14, the interface module 10 has to present both subscribers 12 to CUCM 14 as if they were a single subscriber 12, as CUCM 14 is not configured to separate subscribers 12 from each other. Therefore, in this system, CUCM 14 does not distinguish between Company A and Company B.
One consequence of this is that the two companies cannot have overlapping extension codes. Therefore, if, for example, Company A uses extension codes ranging from 2000 through to 2100, Company B must start their extension codes from 2101. This becomes problematic if Company A later wishes to add additional extension codes, as the new extension codes must follow those used by Company B, and therefore cannot be sequential with the rest of Company A's extensions. Alternatively, Company A must reserve additional extension codes which are not initially used, but are therefore available to them in the future. This latter approach obviously has the drawback that Company A pays for extension codes that they do not use.
Further to this, a particular problem arises if the subscribers 12 wish to map the last four digits of their DDI numbers to extension codes, as is common practice. So, for example, if Company A has DDI numbers ranging from 01234562000 through to 01234562100, they may wish to use the last four digits in that range, i.e. 2000-2100, as extension codes.
However, if Company B has DDI numbers in the range 01162342000 through to 01162342100, the last four digits for numbers in that range are the same as those for Company A. Therefore, if Company A maps the last four digits of their DDI numbers to extension codes, this option is not available to Company B, as the extension codes have already been used.
A conventional method that is used to overcome this problem is known as “extension masking”. This involves adding a prefix to all numbers relating to users belonging to a particular subscriber 12, and hiding the prefix from the users. For example, all users for Company A have the prefix 123456 added to their extension codes, in which case when a user in Company A dials an extension, for example 2000, the prefix is added by CUCM 14, such that the number becomes 1234562000. The user only has to dial the short extension, i.e. “2000”, and the prefix is added automatically in a process which is hidden from the user. This is known in the art as abbreviated dialling. In this way, CUCM 14 is able to direct the call to the correct user within that company. If Company B is assigned the prefix 654321, when a Company B user dials the same short extension (i.e. 2000), the number becomes 6543212000. This enables users of different subscribers 12 to be assigned apparently the same extension codes, because the portion of the extension code which is different is hidden from the users.
A drawback with this approach is that as the interface module 10 does not directly handle incoming calls, there is no way to mask the prefix for DDI numbers, which consequently become very long. Additionally, if the telephone system is integrated with an IT system such that a user is able to place phone calls directly from their computer, for example using Microsoft Outlook, it is not possible to mask the extension in the same way. Therefore, when the user installs the client for the phone system on their machine, they will see the full extension number without the masking, e.g. 1234562000, which is undesirable.
Against this background, it is desirable to provide a call management system which eliminates or substantially alleviates the above mentioned problems which are present in conventional systems.